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ROBERT BOSCH GMBH, 70442 Stuttgart 



Verfahren zur Ubertraaung von digi tal codierten 
Verkehrsnachrichten und Funkempf an ger dazu 

Stand der Technik 

Die Erfindung geht aus von einem Verfahren zur Ubertragung 
von digital codierten Verkehrsnachrichten und einem 
Funkempf anger dazu, nach der Gattung der Anspriiche 1 und 7. 
Aus der DE-35 3 6 820 C2 ist es bereits bekannt , Empf anger 
aufzubauen, bei denen die Verkehrsnachrichten standardisiert 
iibertragen warden. Hierbei sind vorgegebenen Autobahnnummern 
Oder BundesstraSennummern Streckenf uhrungsnamen, meist Orte, 
zugeordnet sowie Standardtexte vorgesehen, so daS auf 
codierte Art und Weise sehr schnell Verkehrsnachrichten 
iibertragen werden konnen . Die Autobahnnummern, die 
Streckenf iihrungsnamen und sonstige Ortsnamen sowie die 
Standardtexte werden hierbei in einem Speicher abgelegt und 
in einem entsprechenden Rundfunkempf anger mitgef iihrt . Tritt 
nun ein Verkehrshindernis auf, so werden die Inf ormationen 
digital in Form von Kurzeln iibertragen und dann im 
Rundfunkempf anger zu einer vollstandigen Meldung 
zusammengesetzt . Dadurch wird erreicht, daS mit sehr wenigen 
Bytes komplette Verkehrsnachrichten iibertragen werden 
konnen, so daS auch bei weniger leistungsf ahigen 
Datenubertragungssystemen sehr viele Verkehrsnachrichten in 
einer relativ kurzen Zeit iibertragen werden. 
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Problematisch wird dies dann, wenn sich 
Autobahnbezeichnungen oder BundesstraEenbezeichnungen 
geandert haben oder aber auch Ortsnamen oder sonstige 
Streckenfuhrungsnamen im Rahmen von Umstrukturierungen 
geandert werden. Dann werden von einem, mit einem 
entsprechenden Speicher ausgestatteten Funkempf anger 
Ortsangaben wiedergegeben, die in dieser Form beispielsweise 
auf Schildern nicht mehr lesbar sind, so daS der Fahrer 
irritiert wird, 

Vorteile der Erfindung 

Erf indungsgemai^ wird nun vorgeschlagen, der eigentlich 
standardisiert ubertragenen codierten Verkehrsmeldung 
mindestens eine Ortsbeschreibung hinzuzuf iigen . Dadurch wird 
es moglich, auch auf geanderte Ortsnamen einzugehen oder 
aber auch Ortsnamen zu libertragen, die in einem 
ursprunglichen Speicher des Funkempf angers nicht vorgesehen 
sind. Da weiterhin die digitale Nachrichteniibertragung iiber 
Funk immer zunimmt , und zudem in neuerer Zeit auch 
Ubertragungsverf ahren zur Verfugung stehen, die auch ein 
hohes Datenauf kommen iibertragen konnen, ist es weiterhin 
moglich, auf einen Speicher im Funkempf anger ganz zu 
verzichten oder nur die vorgegebenen Standardtexte in diesem 
Speicher abzulegen und die Ortsangabe generell an die 
digital codierte Verkehrsnachricht anzuhangen. Dies erhoht 
die Flexibilitat der digital zu iibertragenden 
Verkehrsnachrichten in hohem MaSe . Der Header dient dazu, 
daS der Funkempf anger erkennen kann, daS nicht nur digital 
codierte Verkehrsnachrichten iibertragen werden, sondern den 
digital codierten Verkehrsdaten Ortsinf ormat ionen oder 
sonstige weitere Inf ormat ionen folgen. 

In den Unteranspruchen sind vorteilhafte Weiterbildungen und 
Verbesserung zu den im Anspruch 1 angegebenen Verfahren 
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aufgezeigt. Vorteilhaft ist insbesondere auch den Header 
gleichzeitig zur Verschlusselung der Verkehrsnachrichten zu 
verwenden. Dadurch ist es beispielsweise moglich, 
Verkehrsnachrichten nur dann zur Verfiigung zu stellen, wenn 
bestimmte Dienste empfangen werden oder aber Gebiihren 
entrichtet wurden. Vorteilhaft ist es weiterhin, die 
weiteren Inf ormationen in Klassen aufzuteilen, wobei jede 
Klasse einen Klassenbezeichner und mindestens ein Paket 
aufweist. Durch die Aufteilung in Klassen ist es moglich, 
nicht nur Orts inf ormationen zu iibertragen, sondern auch 
weitere zusatzliche Inf ormationen mit den 

Verkehrsnachrichten zu verbinden, beispielsweise urn Speicher 
im Rundfunkempf anger mit neuen Ortsdaten zu versehen oder 
aber f remdsprachliche Texte von Ortsbezeichnungen zusatzlich 
zu iibertragen, so daS auch auslandische Fahrer die 
Information in ihrer Muttersprache erhalten. Guns tig ist es 
auch, daE die Zahl der folgenden Pakete nach dem 
Klassenbezeichner iibertragen wird. Dadurch wird 
sichergestellt , daS der Funkempf anger in der Lage ist, 
samtliche Inf ormationen einer Klasse vollstandig 
aufzunehmen. Giinstig ist auch weiterhin, jedes Paket durch 
den Pakettyp, das heiSt dem Inhalt der Information und den 
Daten zu bestimmen. Dadurch wird es moglich, in einer Klasse 
Pakete unterschiedlichen Typs zu iibertragen. Vorteilhaft ist 
es weiterhin, das fiir jede Klasse eine Mindestzahl von 
Pf lichtpaketen festgelegt wird. Dadurch wird sichergestellt, 
daS fiir jede Klasse wirklich alle Inf ormationen, die 
zwingend notwendig sind, iibertragen werden. 

Der erf indungsgemalSe Funkempf anger zur Durchf iihrung des 
Verfahrens nach einem der Anspriiche 1 bis 6 weist eine 
Trennvorrichtung von digitalen Daten und Sprachinf ormationen 
und eine Auswerteschaltung zur Auswertung der digital 
iibertragenen Verkehrsnachrichten auf . Hiermit wird es 
moglich, anhand des Headers einerseits die 
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Empfangsberechtigung zu priifen und andererseits zu erkennen, 
welche Information neben den digital codiert libertragenen 
Verkehrsnachrichten ansonsten in dem Nachrichtenpaket 
enthalten ist. Vorteilhaft ist auch, wenn der Funkempf anger 
lediglich einen Speicher fur Standardtexte aufweist . Durch 
diese MaSnahme wird erreicht, daS Standardtexte auf jeden 
Fall nicht iibertragen werden mussen. 

Zeichnung 

Ein Ausfiihrungsbeispiel der Erfindung ist in den Zeichnungen 
dargestellt und in der nachf olgenden Beschreibung naher 
erlautert . Es zeigen 

Figur 1 einen Funkempf anger zur Realisierung der Erfindung, 
Figur 2 den Aufbau eines Datenwortes gemaiS der Erfindung 
Figur 3 den Aufbau eines Datenwortes fur die Klasse und 
Figur 4 den Aufbau eines Datenwortes fur ein Paket . 

Beschreibung des Ausfiibrungsbei spiels 

Figur 1 zeigt einen Funkempf anger , beispielsweise einen 
Rundfunkempf anger mit einer Antenne 1, an den ein 
Rundfunkempfangsteil 2 angeschlossen ist. Am Ausgang des 
Rundfunkempfangsteils 2 steht das decodierte empfangene 
Signal zur Verfiigung, Beim bekannten FM-Rundfunk werden 
neben den gesprochenen Worten und der Musik auch 
gesprochener Verkehrsfunk sowie liber das Radiodatensystem 
RDS digital codierte Verkehrsnachrichten ausgestrahlt . Die 
Codierung basiert dabei auf einem Standard, der speziell fiir 
die eingeschrankte Datenkapazitat von RDS entwickelt wurde . 
Am Ausgang des Empfangers 2 werden nun die empfangenen 
Inf ormationen getrennt . Die gesprochenen Worte werden dem 
Verstarker 3 zugefiihrt und uber den Lautsprecher 4 dem Horer 
horbar gemacht . Die digital ubertragenen Daten werden dem 



- 5 - 



R. 35277 



Decoder 5 zugefuhrt, an dessen Ausgang ein serielles Signal 
mit sogenannten TMC Daten zur Verfiigung steht. Diese warden 
nun im Microrechner 6 verarbeitet und dem Fahrer eines 
Fahrzeuges akustisch oder optisch zur Anzeige gebracht . 

Aufgrund der geringen Ubertragungsbandbreite , der 
Kanaleigenschaf ten und anderer Zielsetzungen, beispielsweise 
die Sprachunabhangigkeit , warden bei der heutigan 
Ubartragung von Verkahrsnachrichten auf standardisiertar 
Basis das Mitfiihren von Listen und Tabellen in den 
Endgeraten fur die Decodierungen der empfangenen Meldungen 
gefordert, wie dies in der eingangs genannten Patentschrif t 
beschrieben ist . TMC-Meldungen dienen heutzutage nicht nur 
zur Information des Fahrers, sondern auch zur Dynamisierung 
der Navigation, das heiSt bei der Berachnung vor Fahrtrouten 
in Navigationssystemen wird die Verkehrslage beriicksichtigt , 
die per TMC ubertragen wurde, so daS beispielsweise die 
Navigation bereits Hinweise gibt, wie ein Stau zu umfahren 
ist . 

Das Problem bei TMC liegt in dem im Endgerat mitgefiihrten 
Listen und Tabellen, in denen insbesondere die 
Ortscpdetabelle zu nennen ist, die die Liste samtlicher Orte 
fiir das fur die Verkehrsmeldung relevant e StraSennetz 
gespeichert hat. Weitarhin ist aine Ereignisliste 
mitzufiihren, in der die moglichen Eraignisse aufgefiihrt 
sind, beispielsweise die Lange eines Staus und dar Grund, 
warum ein Stau aufgetraten ist. Abgesehen von dem benotigten 
Speicherplatz ist die Aktualisierung der Ortscodatabellen 
ein Problem und es ist weiterhin zu bedenken, daS nicht alle 
Verkehrsmeldungen codiert warden konnen, insbesondere wenn 
durch das Sparren odar Hinzukommen weiterer StraSen die 
Ortscodetabelle nicht mehr aktuell ist. Die Ereignisliste 
erlaubt nur die Verwendung der vordef inierten Ereignisse. 
Neue Ereignisse konnen iiber TMC in seiner bakannten Form 
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nicht iibertragen werden. Andererseits erfreut sich TMC einer 
zunehmenden Beliebtheit, da durch den gewonnen Standard mit 
sehr wenig Information ein grower Inf ormationsinhalt 
vermittelt werden kann. 

In zunehmendem MaSe findet TMC nicht mehr nur im FM Rundfunk 
Anwendung, sondern wird ebenfalls in Verbindung mit 
GSM-Funktelef onen eingesetzt, die sich auch den TMC-Standort 
mit den kurzen Ubertragungszeiten zunutze macht . Auch bei 
neuen f ortschrittlichen Rundf unkiibertragungssystemen, wie 
beispielsweise dem Digital Audio Broadcasting (DAB) ist TMC 
im Gesprach. Aufgrund der f ortentwickelten Technik sind 
jedoch die neueren Ubertragungsverf ahren in der Lage, 
erheblich hohere Datenraten zu iiberragen, als dies bei RDS- 
TMC der Fall ist . 

Wesentlich ist jedoch alien Funkemp fangs systemen gemeinsam, 
daS nach dem Empfang und der Demodulation der Information 
eine Trennung der Sprachinf ormation und TMC- Inf ormat ion 
erfolgen muS, die in geeigneter Weise in einem Rechner 
verarbeitet werden mufi. In Figur 2 ist nun ein Verf ahren ^ zur 
Ubertragung von digitalcodierten Verkehrsnachrichten 
aufgezeigt, das zum an sich bekannten TMC-Verf ahren 
riickwarts kompatibel ist, das heiSt unter der Verwendung des 
bekannten TMC-Verf ahrens zusatzliche 

Informationsmoglichkeiten anbietet . Eine Standard TMC 
Meldung 13 wird erweitert ausgestrahlt . Die erweiterte TMC- 
Meldung 10 setzt sich aus einem Header 12 und der 
eigent lichen Meldung 11 zusammen. Die Meldung 11 selbst 
besteht wiederum aus einer standardisierten TMC-Meldung 13, 
so wie mindestens einer Zusatzinf ormation 14, 15 und 16. 
Wird ein Header 12 der TMC-Meldung 13 vorangestellt , so mufi 
mindestens eine Zusatzinf ormation 14 vorhanden sein, die mit 
iibertragen wird. Diese Zusatzinf ormation 14 muS zudem eine 
Ortsinf ormation sein. Die weiteren Zusatzinf ormat ionen 15 
und 16 sowie weitere Zusatzinf ormation sind optional und 
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dienen dazu, verschiedene Klassen von Inf ormat ionen zu 
iibertragen. 

Der Header 12 ist notwendig, urn erkennen zu konnen, daS es 
sich urn eine erweiterte TMC-Inf ormation handelt. Der Header 
12 kann Inf ormat ionen dariiber enthalten, wieviel 
Zusatzinformationen 14, 15 und 16 der eigentlichen TMC- 
Meldung folgen und dient dazu, bei Bedarf eine 
Verschliisselung der TMC-Meldung durchzuf iihren . Eine solche 
Verschliisselung mulS signalisiert werden und gleichzeitig muS 
angegeben werden, urn welche Art der Verschliisselung es sich 
handelt. Im Header kann daher auch ein 

Verschliisselungsindikator eingearbeitet sein. Somit wird es 
moglich, die TMC-Meldung unterschiedlich zu verschliisseln 
und diensteabhangig unterschiedliche TMC- Inf ormat ionen 
beispielsweise uber GSM oder DAB zu iibertragen . So ist es 
beispielsweise moglich, einem Dienstanbieter A eine erste 
Verschliisselung zuzuordnen und einem Dienstanbieter B eine 
andere Verschliisselungsmethode . Somit ist es auch mittels 
GSM moglich, entweder iiber den Short -Message -Channel oder 
iiber iibliche GSM-Signale abhangig von Diensteanbieter 
unterschiedliche Verkehrsinf ormat ionen zu iibertragen. Der 
Header ist daher in der Lage, neben der Kennzeichnung einer 
erweiterten TMC-Meldung noch weitere Aufgaben wahrzunehmen, 
wie namlich die Verschliisselung und die Anzeige, wieviel 
Zusatzinformationen zu erwarten sind. 

Wahrend der Aufbau der TMC-Meldung 13 standardisiert ist, so 
da£ hier nicht naher darauf eingegangen werden muS, konnen 
die Zusatzinformationen unterschiedlich aufgebaut sein. 
Wichtig ist, daS zumindest eine Zusatzinf ormat ion 14 eine 
Ortsbeschreibung enthalt, da ansonsten eine erweiterte TMC- 
Meldung keinen Sinn machen wiirde . 
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Die Zusatzinf ormation ist im Detail in Figur 3 dargestellt. 
Die Zusatzinf ormation, die unterschiedliche Inhalte haben 
kann, ist in sogenannte Klassen 20 aufgeteilt, wobei sich 
die Klassen aus einem Klassenbezeichner 21, aus einer 
5 Klassenlange 22, die die Anzahl der nachf olgenden Pakete 

beschreibt und aus den Pakten 23, 24 zusammensetzt , wobei 
die Zahl der Pakete lediglich durch die Klassenlange 22 
bestimmt ist. Wichtig hierbei ist noch, daS bestimmten 
Klassen mit einer bestimmten Klassenbezeichnung eine 

10 Mindestmenge von Pf lichtpaketen zugeordnet ist, so daS eine 

optimale Auswertung der TMC-Daten moglich ist, Zusatzlich 
Jt^, konnen jedoch beliebige weitere Pakete optional angehangt 

werden. Die Definition der Klasse 20 ist im iibrigen auch fiir 
die TMC-Meldung 13 selbst anwendbar . Als Klassenbezeichner 

15 wird dann an der Stelle 21 der Code fur TMC-Meldungen 

eingesetzt, wahrend die Klassenlange die Anzahl der TMC- 
Meldungen kennzeichnet . Als Pakete 23 und 24 folgt dann 
jeweils eine TMC-Gruppe. Bei einem Paket ist daher eine TMC- 
Meldung zu iibertragen, sind mehrere TMC-Meldungen zu 

20 iibertragen, sind mehrere Pakete zu bilden. Die 

standardisierten Verkehrsmeldungen erlauben es auch, daS 
eine Verkehrs information nicht nur aus einer Gruppe, sondern 
aus bis zu funf Gruppen bestehen kann. In diesem Falle 
mussen insgesamt fiinf Pakete 23, 24 fiir eine Verkehrs me 1 dung 

2? aufgewandt werden. Das Erkennen der Zusammengehorigkeit der 

Pakete wird aus Figur 4 ersichtlich, da hier aufgezeigt ist, 
daS jedes Paket 23 und 24, dort mit 25 bezeichnet, 
einerseits aus dem Typ 26 und dem Daten 27 besteht. An der 
Typkennzeichnung 26 ist nun zu erkennen, ob die 

3 0 nachf olgenden Daten 2 7 zu einem vorhergehenden Paket 

gehoren, oder aber ob die Daten 27 in sich selbstandig 
interpretierbar sind. Bei TMC-Meldungen konnen nun aufgrund 
des Aufbaus der Klasse mehrere Verkehrsmeldungen zusammen 
liber den TMC-Meldungsbaustein 13 iibertragen werden. 



35 
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Wie bereits erwahnt, muS eine der Zusatzinf ormationen 14 
eine Klasse zur Ortsbeschreibung enthalten. Wobei hier 
I nf ormationen von den in der TMC-Meldung enthaltenen 
codierten Ortsangaben enthalten sind. Abhangig von der Art 
5 der in der TMC-Meldung beschriebenen Situation benotigt man 

fur eine solche Ortsbeschreibung einen oder mehrere 
verschiede Pakettypen. Die Kombination von Paketen 
hinsichtlich Anzahl , Typ und Reihenfolge fuhren zur Bildung 
mehrerer verschiedener Klassen, wobei diese Klassen 
10 Pf lichtangaben enthalten. Pf lichtangaben fur die 

Ortsinf ormation sind beispielsweise Pakete fur die 
V^V Strafienbezeichnug, fiir den Namen oder Kurzbezeichnung der 

Strafie, deren Numerierung, Koordinaten, Audiobausteine und 
ahnliches zu sehen. Hierdurch wird es moglich, den in 
15 codierter Form iibermittelten TMC-Daten Inhalte hinzuzuf iigen, 

die standig zu aktualisieren sind. Fiir den Empf anger bietet 
sich dann der Vorteil, daS der eingangs erwahnte Speicher 
beispielsweise bei einem GSM Handf unk-Gerat nicht vorhanden 
sein muS, da die Daten zur Codierung des TMC-Paket 
20 anschlieSend in der Klasse Ortsinf ormation mit iibertragen 

werden. Dadurch wird bereits eine Ausgabe der Information 
auf dem Display moglich. Werden ' zusatzlich noch 
Audioinf ormationen iibertragen, wird eine Sprachwiedergabe 
erreicht. Kommen zusatzlich noch Koordinaten hinzu, konnen 
diese Koordinaten dazu verwendet werden, sofort zum 
Navigationsgerat uberfuhrt zu werden, so daS eine neue 
Routenberechnung dadurch vereinfacht wird. In weiteren 
Klassen konnen nun applikationsspezif ische Anwendungen 
abgelegt werden, beispielsweise Zusatzinf ormationen fiir 
3 0 spezielle Navigationssysteme Hinweise auf Sehenswiirdigkeiten 

Oder besondere Gef ahrangaben, wie starkes Gefalle, Glatteis 
Oder Kurve . 

Der Microprozessor 6 in Figur 1 enthalt zusatzlich einen 
35 Speicher 7, in den in einem speziellen Ausf iihrungsbeispiel 
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der Erfindung die normierten Ereignisse abgelegt sind. Da 
die normierten Ereignisse sich weniger haufig andern als 
Ortsdaten, kann auch durch die Erfindung ein gemischter 
Betrieb erreicht werden, indem namlich ein Teil der 
5 notwendigen TMC- Inf ormationen, insbesondere die Ereignisse, 

wie „3 km Stau" und ahnliches in einem Speicher des 
Funkempf angers abgelegt wird wahrend andere Inf ormationen, 
deren Anderung mehr wahrscheinlich ist, wie beispielsweise 
Ortsnamen, iibertragen werden. Dies ist jedoch nicht 

10 zwingend. Selbstverstandlich ist es moglich, gar keinen 

Speicher vorzusehen und auch die Ereignisse als 

lll^ Zusatzinf ormation zu iibertragen, oder aber eine komplette 

Ortscode- und Ereignisliste vorzuhalten und nur solche 
Inf ormationen als erweiterte Themen zur Information zu 

15 iibertragen, die in der Ortscodeliste nicht enthalten sind. 

Wesentlich dabei ist, daS die TMC-Meldung selbst mit der 
bereits genormten TMC-Meldung kompatibel ist. 

In der folgenden Tabelle 1 sind beispielhaft verschiedene 
20 Pakettypen aufgefiihrt, die als Paket in einer Klasse von 

Zusatzinf ormationen ubertragen werden konnen . 



Nr 


Paket -Typ 


Typ- 
Lange 


Beschreibung 


0 


Zahl 


5 Byte 


TMC-Gruppe 


1 


Zahl 


8 Byte 


Location: ECC+ 
CC+LocDB#+Locationcode 
(nach ALERT C) 


2 


Zahl 


1 Byte 


StraSenklasse 

(Primary, Secondary, etc . , 

codiert als 1,2, etc.) 


3 


Str . Bezeich 


n Byte 


StraSenkennung (z .B. 
A, ST, etc . ) 


4 


Str . Bezeich 


n Byte 


StraSennummer 
(z.B.4,1204 etc.) 
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Nr 


Paket-Typ 


Typ- 
Lange 


Beschreibung 


5 


Text 


n Byte 


StraSensuf f ix {z.B. 
n, old, etc . ) 


6 


Name 


n Byte 


StraSenname (z.B. Kolner 
Ring) 


7 


Name 


n Byte 


1 . Segmentname 


8 


Name 


n Byte 


2 . Segmentname 


9 


Text 


n Byte 


Locationtyp (nach 
ENV12 313-3 , Z .B. Al , 0, 
PI. 13 .etc. ) 


10 


Text 


n Byte 


Locationtyp -Bezel chnung 
(z.B. Ausfahrt) 


11 


Name 


n Byte 


Locationname (z.B. 
Hildesheim-Drispenstedt ) 


12 


Nummer 


n Byte 


Ausf ahrtnummer (z -B . 17b) 


13 


Text 


n Byte 


Gebietsbezeichnung (z.B. 
Regierungsbezirk) 


14 


Name 


n Byte 


Gebietsname (z.B. 
Hannover) 


15 


Nummer 


n Byte 


Um 1 e i t ung s numme r 


16 


Text 


n Byte 


Umleitungssuf f ix 


17 


KOO 


18 Byte 


Punkt -Koordinate (WGS84 ) 


18 


Koo 


3 6 Byte 


Koordinaten-Paar (WGS84 ) 


19 


Zahl 


8 Byte 


Cross -Referenz auf 
anderen Location-Code 


20 


Str . Bezeich 


n Byte 


Eu r op a - S t r ai5.en - Numme r 
(z.B. 4 fiir die E4) 


21 


Audio 


n Byte 


Audio-Datei 


22 


Nummer 


1 Byte 


Versionsnummer (der 
Location -Da tenbank) 


23 


Text 


n Byte 


Freier Text 
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Nr 


Paket-Typ 


Typ- 
Lange 


Beschreibung 


24 




n Byte 


Location- List en- Zeile 
(zur Aktualisierung von 
Listen im Endgerat) 


Tabelle 2 zeiat unterschiedliche Klassenstrukturen auf . 


Nr 


Pf licht - 
pake t e 


Op t i o - 

nale 

Pakete 


Beschreibung 


1 


1, 9, 10, 17 


12, 13 


Gebietsmeldung 


2 


1,2,4,7,8,17 


3,5,6,1 
2 , 13 , 14 
19 


Stral5en-oder Segment - 
Mel dung 


3 


1, 2 , 4 , 9 , 10 , 1 
3 , 16 


3,5,6,7 
8 , 12 , 18 
19 


Punkt in Stadt 


4 


1,2,4,7,8,9, 
10, 11, 16 


3,5,6,1 
2 , 13 , 14 
15, 18 


Punkt auSerhalb einer 
Stadt 


5 


1,2,4,9,10,1 - 
3, 16 


3,5,6,1 
2 , 18, 19 


2 Punkte in einer Stadt 


























9 


2,4,7,8,1,9, 
10, 11, 16, 1, 9 
, 10, 11, 16 


3,5,6,1 
2 , 14 , 15 
18, 19 


2 Punkte, beide auSerhalb 
einer Stadt 










17 


245 




Location-Liste -Update 











Hier ist beispielsweise aufgefiihrt, dalS die Klasse 1 mit 
bestimmten Nummern gemaS Tabelle, sowie zusatzlich zwei 
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optionale Pakete ubertragen warden konnen, die jedoch nicht 
zwingend sind. Ahnlich ist dies bei den iibrigen Klassen zu 
sehen. 

Im folgenden soil der Weg der Codierung einer erweiterten 
TMC-Meldung exemplarisch aufgezeigt warden. Folgende Meldung 
ist eine typische Verkehrsf unkmeldung fur eine Storung auf 
einer Autobahn: 

„A4 Olpe Richtung Koln, zwischen Bergisch-Gladbach Moitzfeld 
und Bergisch-Gladbach Bensberg 2 km stockender Verkehr" . 

Wird diese Verkehrsmeldung nach dem gegebenen Standard 
hexadezimal codiert, ergibt sich folgende Darstellung: 08 
086E 2B74 . Dies ware die Information, die nunmehr als 
Verkehrsmeldung als TMC-Meldung 13 in einem Paket 23 
ubertragen wiirde . Als Klasse fiir die Ortsinf ormation wird, 
aufgrund der in der Verkehrsmeldung beschriebenen Situation 
im Ausfiihrungsbeispiel am besten die Klasse 9 gemaS Tabelle 
2 benutzt. Diese hat den Aufbau, wie er in der Tabelle 3 
dargestellt ist. 



Tabelle 3 



Klasse d. 
Ortsinfor 
mationen 


Pf lichtpakete 
(Pakettypen der 
Ortsinf orxnat ion) 


Optionale Pakete 
(Pakettypen der 
Ortsinf ormation 




9 


2,4,7,8,1,9,10, 
11, 16, 

1, 9, 10, 11, 16 


3,5,6,12,14,15, 
18, 19 


2 Punkte, 

beide 

auSerhalb 

einer 

Stadt 



Ausfiihrung der Pf lichtpakete : 
Element 2: Strassenklasse : 1 
Element 4: Strassennr.: 4 



Element 7 : Olpe 
Element 8 : Koln 

1. Element 1: ECC=EO, CC=D, LocDB#=l ; Locat ioncode=2B74h 
1. Element 9: PI . 3 

1. Element 10: Bergisch-Gladbach Moitzfeld 
1. Element 11: 2 0 

1. Element 16: 007642312,051238721 

2. Element 1: ECC=:E0 , CC=D, LocDB# = l ; Locat ioncode = 2B73h 
2. Element 9: PI . 3 

2. Element 10: Bergisch-Gladbach Bensberg 
2. Element 11: 19 

2. Element 16: 007542342,051029628 
Ausfiihrung der optionalen Pakete 

Element 14: 50 (Da die U50 von Moitzfeld n. Bensberg fiihrt) 
Element 19: 40 (Da die A4 Teil der E40 ist) . 

Aufgrund der nun vorliegenden Inf ormationen ist es nicht nur 
moglich, ein Nagivat ionsgerat mit den notwendigen Daten zu 
iibertragen, sondern die oben erwahnte Verkehrsf unkmeldung 
kann ein eindeutig zuriickgewonnen werden, ohne daS 
irgendwelche Informationen im Funkempf anger gespeichert sein 
miissen . 

Als Zusatzinf ormationen in den weiteren Feldern 15 und 16 
konnen beispielsweise die Ortsangaben fiir den Stauanfang und 
das Stauende, Zwischenstiit zpunkte oder der aktuelle 
Zeitverlust iibertragen werden, der sich aufgrund der 
maximalen Verkehrsdichte der StraSe ergibt . Weiterhin sind 
als zusatzliche Informationen die Ereignisklasse 
iibertragbar, oder nahere Beschreibungen . Anhand der 
Ereignisklasse ist es dann moglich, die Verkehrsmeldungen 
nach verschiedenen Kriterien zu sortieren. 
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R. 352 



10.02.99 Fd/Mv 

ROBERT BOSCH GMBH, 70442 Stuttgart 
Anspriiche 

1. Verfahren zum Ubertragen von digital codierten 
Verkehrsnachrichten, wobei die Verkehrsmeldungen nach 
einem standardisierten Aufbau, insbesondere nach dem TMC- 
Verfahren, ubertragen werden, dadurch gekennzeichnet , daS 
den digital codierten Verkehrsmeldungen (13) ein Header 
(12) vorangestellt wird und daS der digital codierten 
Verkehrsmeldung (13) mindestens eine weitere Information 

(14, 15, 16) folgt, wobei eine dieser Inf ormat ionen (14) 
eine Ortsbeschreibung enthalt. 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet , daS 
der Header (12) zur Verschliisselung der 
Verkehrsnachrichten dient . 

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, 
daS die weiteren Inf ormationen (14, 15, 16) in Klassen 
(20) aufgeteilt sind, wobei jede Klasse (20) einen.. 
Klassenbezeichner (21) und mindestens 1 Paket (23, 24) 
aufweist. 

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daS 
die Zahl der folgenden Pakete (23, 24) nach dem 
Klassenbezeichner (21) ubertragen wird. 

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daS 
jedes Paket (23, 24) durch den Typ (26) und die Daten 
(27) bestimmt wird. 
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R. 35277 



6. Verfahren nach einem der Anspriiche 2 bis 5, dadurch 
gekennzeichnet , daS durch die Klasse die Zahl der 
Pf lichtpakete festgelegt wird. 

7 . Funkempf anger zur Durchf iihrung des Verf ahrens nach einem 
der Anspriiche 1 bis 6, mit einem Funkempf angsteil (2) 
mit einer Trennvorrichtung von digitalen Daten und 
Sprachinf ormationen, mit einer Auswerteschaltung (5) zur 
Auswertung digital codiert iibertragener 

Verkehrsnachrichten, insbesondere TMC-Nachrichten, und 
einer Recheneinrichtung (6) zum Auswerten der digital 
empf angenen Inf ormationen . 

8. Funkempf anger nach Anspruch 7, dadurch gekennzeichnet, 
daS er nur einen Speicher (7) fiir Standardtexte 
aufweist . 



- 17 - 



R. 3S211 



10.02.99 Fd/Mv 

ROBERT BOSCH GMBH, 70442 Stuttgart 



Verfahren zur Ubertraauna von digi tal codierten 
Verkehrsnachrichten und Funkempf anaer dazu 

Zusammenf assung 

Es wird ein Verfahren zur Ubertragung von digital codierten 
Verkehrsnachrichten vorgeschlagen, wobei die 
Verkehrsnachrichten in einem standardisierten Aufbau 
libertragen werden. Den Verkehrsnachrichten selbst wird dabei 
ein Header vorangestellt und der digitalen Verkehrsmeldung 
wird mindestens eine weitere Information nachgeordnet , wobei 
diese Information eine Ort sbeschreibung enthalt . Durch die 
erf indungsgemaSe MaSnahme wird erreicht, daiS auch 
Verkehrsmeldungen ubertragen werden konnen, die im 
standardisierten Aufbau nicht moglich oder nicht vorgesehen 
sind. 
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